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-One  of  the  responses  to  the  need  for  effective  interaction  in  the 
use  of  computers  for  a  design  project  is  the  supersystem  concept 
proposed  for  ICES,  the  Integrated  Civil  Engineering  System.  The 
supersystem  is  defined  as  the  cooperative  effort  on  the  part  of  the 
designers  of  several  problem  oriented  computer  capabilities  to 
implement  project  oriented  capabilities  by  allowing  each  of  their 
problem  oriented  subsystems  to  reference  a  single  file  of  project 
data.  The  supersystem  would  allow  design  interaction  by  having  each 
of  the  problem  oriented  computer  subsystems  reference  a  single  file 
of  information  specifying  the  project. 

-Future  work  in  the  application  of  computers  to  interactive  and 
project  oriented  design  in  the  building  industry  will  have  to 
concentrate  on  the  file  structure  to  be  used  in  the  implementation  of 
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Abstract 


The  problem  of  effective  communication  In  the  process 
of  building  design  and  construction  Is  widely  recognized. 

The  Involvement  of  several  design  disciplines  combtned  with 
the  tendency  for  designers  to  work  in  <Hstl nct-off  lces-  — *- -  ■ 
results  In  little  capacity  for  them  to  investigate  the 
influence  of  their  design  decisions  on  other  design  areasv 

One  of  the  responses  to  the  need  for  effective 
Interaction  In  the  use  of  computers  for  a  design  project  Is 
the  supersystem  concept  proposed  for  ICES,  the  -4ntegrated  — 
Civil  Engineering  System.  The  supersystem  Is  defined  as  the 
coopers  1 5  ve-ef  fort  on  -the  part  of -.the  Jesl  2  n  er  s  of  s  evora  l_- 
problem  oriented  computer  capabilities  to  I mplemenf  "jpT'oJ^ect 
oriented  capabilities  by  allowing  each  of  their  problem 
oriented  subsystems  to  reference  a  single  file  of  project 
data.  The  supersystem  would  allow  design  Interaction  by 
having  each  of  the  problem  oriented  computer  subsystems 
reference  a  single  file  of  information  specifying  the 
project.  ■■■' 

Future  work  In  the  application  of  computers  to 
Interactive  and  project  oriented  design  In  the  building 
Industry  will  have  to  concentrate  on  the  file  structure  to 
be  used  in  the  Implementation  of  a  computer  building  design 
supersystem. 
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The  process  of  building  design  and  const  ruction 
Involves  much  handling  and  manipulation  of  data.  What 
starts  out  as  the  single  desire  of  a  client  for  a  building 
develops  Into  a  full  set  of  working  drawings  and  specifi¬ 
cations  by  the  end  of  the  design  ohase  of  the  process  and 

- — udtlmateiy  4 Tn+shes  an  existing  bui  1  Jlna.  When  one _ 

....  examines  the  data  flow  In  the  building  process  In  light  of 
the  data  manipulating  and  storage  capabilities  of  the  modern 
electronic  digital  computer,  one  expects  at  first  to  find  a 
broad  utilization  of  the  computer  throughout  the  building 
Industry.  Yet  when  one  examines  the  degree  to  which 
computers  are  actually  used  In  the  building  process,  the 
findings  are  generally  very  disappointing.  Few  of  the 
design  disciplines  Involved  with  the  building  process  make 
any  significant  use  of  the  computer  and  even  In  these  few 
Instances,  the  applications  are  In  completely  Isolated 
areas.  While  many  design  areas  Involved  In  building  design 
have  been  considered  for  computer  Implementation,  most 
efforts  have  been  at  the  proposal  stage  only.  The  two  major 
exceptions  have  been  the  areas  of  structural  analysis  and 
construction  project  scheduling  for  which  large  scale 
systems  have  been  Implemented. 

The  reasons  for  the  pattern  of  usage  that  one  finds 
reflect  problems  both  of  economics  and  degree  of  difficulty. 
As  would  be  expected,  engineers  have  attacked  those  problems 
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first  that  seemed  most  promising  of  solution.  Since  both 
structural  analysis  and  construction  scheduling  are  quite 
straightforward  In  an  analytical  sense  and  require  much  data 
processing,  they  were  computerized  first.  More  significant, 
however,  is  the  fact  that  these  two  areas  arethe  exc  1  us  I  ve 
domains  of  two  distinct  segments  of  the  building  process, 
the  structural  engineers  and  the  contractors.  Each  Invested 
In  the  software  which  It  felt  would  make  Its  operations  more 
efficient.  Neither  was  particularly  motivated  to  spend 
money  to  make  the  Job  of  someone  else  more  efficient. 

The  reasons  for  this  pattern  of  usage  can  also  be 
found  In  the  approach  taken  by  designers  of  computer  systems 
to  the  whole  question  of  Information.  The  techniques  for 
Information  handling  developed  for  the  analytic  problem¬ 
solving  systems  have  In  the  past  almost  never  considered 
Information  requirements  beyond  the  scope  of  the  system 
being  Implemented.  There  has  been  little  motivation  to 
consider  the  Information  requirements  of  other  systems 
because,  first,  there  were  few  enough  of  these  systems 
Implemented  on  the  computer  to  begin  with,  and  secondly, 
there  had  simply  been  no  co-ordination  which  would  result  In 
the  Information  being  used  even  If  It  were  made  available. 
Furthermore,  Information  has  generally  been  structured  so  as 
to  optimize  processing  In  view  of  the  algorithms  used  by  the 
subsystem  structuring  It. 

Information  has  always  been  considered  as  a  static 
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-Collection  of  data  val ues  which  were  Inout  at  the  beginning, 
of  a  computer  run  and  completely  purged  from  the  computer  at 
the  end  of  the  run.  There  has  been  almost  no  attempt  to 
view  Information  from  the  point  of  view  t-b»  project,  as  a 
highly  structured  complex  wM ch  starts  as  a  single  Idea  and. 
wh i ch  ends  after  great  deYel opmant  ;as  an  extremely  complex  — 
-set  of  drawl nes  and  spec  1 f i cat  tons .  In  those  few  Instances 
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where  data  has  been  organized  by  a  computer  system  on . 

secondary  storage.  It  has  been  done  in  such  a  way  as  to  be 
of  use  only  to  the  system  which  so  organized  It. 

Building  data  management,  then.  Is  an  attemot  to 
solve  the  very  complex  problems  of  automating  the  flow  of 
Information  between  various  problem  oriented  comouter 
capabilities  used  In  the  design  and  construction  of 
buildings,  computer  capabilities  both  existing  and  proposed. 
Building  data  management  is  the  concept  of  data  transfer 
applied  to  the  realm  of  building  systems.  Data  transfer 
attempts  to  make  It  possible  for  independently  conceived  and 
Independently  executed  computer  systems  to  communicate  their 
results  with  each  other. 
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The  concept  of  data  transfer  Is  not  a  new  one.  The 
designers  of  ICES,  an  acronym  for  the  INTEGRATED  CIVIL 
ENGINEERING  SYSTEM  (1),  have  attacked  the  problem  o*r  lit:', 
transfer  from  th«*  very  beginning  of  their  effort.  The  ICES 


system  was  visualized  as  a  computer  oriented  system  used  by 
a  collection  of  problem  oriented  subsystems  (2).  The 
analogy  was  made  to  a  wheel  in  which  the  system  comprised 
the  axle/  the  various  subsystems  the  spokes,  and  data 
-transfer  was  to  have  been  a  kind  of  rim  uniting  all  of  the 
subs  y.&  teals  via  communications  capab II I tes  ( see  F  tgu re  t  - 1 ) . 

_ However/  i f  one  examines  leas  System  Design  (3),  the 

guiding ^philosophy  for  the  IOCS  system,  one  discovers  that 
there  are  two  areas  of  the  system  that  were  not  generally 
Implemented.  They  are  the  relational  data  structure 
capabilities  (4)  and  data  transfer.  For  several  years  much 
work  was  put  into  the  implementation  of  both  of  these  areas. 
While  some  results  were  obtained  in  the  former  area  (5),  r»o 
real  working  system  of  any  capability  resulted  In  the 
latter. 

M  the  first  efforts  to  implement  data  transfer,  the 
ICES  researchers  attacked  the  general  problem  of  information 
flow  within  the  computer.  The  work  was  motivated  by  their 
strong  feeling  that  subsystem  designers  should  be  given  f ul 1 
freedom  for  design  of  in-core  data  structures  most  suited  to 
the  problem  and  algorithms  with  which  they  were  working. 

Yet,  when  these  Independent  systems  attemoted  to  each  solve 
a  different  aspect  of  the  same  project,  the  need  arose  for 
them  to  communicate  results  with  each  other.  The  early  work 
resulted  In  a  proposal  for  a  Oata  definition  language  (6), 
but  most  felt  that  an  appropriate  solution  to  the  problem 
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FIGURE  1-1 
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was  still  yet  to  be  found.  In  the  Interim,  of  coure,  data 
transfer  was  actually  acompt I  shed  by  having  the  engineer 
using  the  various  subsystems  on  a  project  manually  transfer 
Information  from  the'prlntout  of  one  set  of  results  to  the 
problem  language  input  of  the  second  subsystem  (See  Figure 
4-2). 

In  1,958,  tons  (7)  performed  a  study  of  the  efforts  In 
data  transfer  In  the  context  of  the  ICES  system.  His  major 
conclusion  was  that  while  the  attemot  to  solve  the  problem 
of  general  data  sharing  between  computer  systems  had  borne 

t 

little  fruit,  there  was  some  reason  to  be  hopeful  that  a 
less  genera,  approach  to  the  problem  might  give  better 
results.  He  distinguished  between  the  concepts  of  the 
system  and  the  subsystem  and  Introduced  the  concept  of  a 
supersystem.  The  system  Is  comprised  of  those  capabilities, 
generally  oriented  toward  strictly  computer  tasks,  that  are 
used  by  all  of  the  subsystems.  Subsystems  are  comnrlsel  o<* 
capabilities  oriented  toward  some  specific  engineering 
problem  area.  The  supersvstem  Is  defined  as  a  groun  of 
loosely  organized  subsystems,  each  oriented  toward  % 
specific  problem  area,  but  jointly  working  towar  1  the  goal 
of  a  project  Implementation,  orincioally  by  sharing  a  common 
data  base  stored  permanently  on  a  secondary  Stonge  device. 
It  Is  the  matter  of  the  orientation,  problem  versus  project, 
that  distinguishes  a  subsystem  from  a  supersystem.  Thus, 


while  STRUDl,  the  structural  design  language.  Is  capable  of 


analyzing  and  selecting  members  for  the  structural  frame  for 
a  building,  it  is  not  capable  of  taking  the  entire  building 
project  or  even  the  structural  part  from  inception  to 
completion.  The  building  design  comprises  many  problem 
■ar eas,  each  ofwhi ch  might  require  a  suhsys tea  of  the  ftJ z* 
and  complexity  of  STRUDL. 

The  Implementat Ion  of  data  transfer  Is  Imoortanc  not 
only  for  the  concept  of  a  supersystem  but  for  the  way  that 
engineering  is  practiced.  Engineers,  while  (n  school#  solve 
problems.  Each  problem  is  a  close  look  at  some  small, 
specific  engineering  task.  When  the  problem  is  solved#  the 
answer  Is  graded  and  no  more  Is  done  with  It.  Engineers#  as 
practicing  professionals,  work  on  projects.  They,  too# 
solve  problems.  In  distinction  to  the  work  of  students# 
however,  the  answers  to  their  problems  are  Integrated  Into 
the  larger  project  effort.  These  answers  are  considered  In 
their  ramifications  with  other  “answers"  for  other  problem 
areas  of  the  project  and  must  be  considered  as  part  of  all 
the  project  data. 

Computer  efforts  in  engineering  to  date  have  been 
aimed  at  giving  problem  solving  capabilities.  And  just  as 
looking  at  an  engineering  project  as  a  series  of  problems 
fragments  the  concept  oE  a  project  effort,  so  have  these 
computer  capabilities  tended  to  fragment  the  work  that  can 
be  done  for  a  project  with  a  computer.  This  can  be  observed 
In  the  tendency  of  engineers  to  require  that  a  problem  be  of 
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sufficient  si  ze  or  cornel  ex  1  ty  In  order  to  justify  soWInjt -It 
with  a  computer.  The  fragmentation  has  put  an  artificial 
barrier  between  the  engineer  and.  hl.s  .problem  soJ_yin£__to_d1. 
Now  In  order  to  overcome  the  tendency  toward 


capabllltles  or  supersystems,  the  whole  approach  “of 
eng  1  nee r I ng  computer  developrdent'm^s't^e^c^examl nedv 
Engineering  computer  technologists  can  re-orient  their 
efforts  and  work  toward  the  development  of  project  oriented 
subsystems  -  unique,  all-encompassing  computer  systems. 

These  would  be  large  scale  efforts  and  might  well  result, 
for  example.  In  a  STRUDl-like  subsystem  for  bridge  design, 
another  STRUnL-llke  subsystem  for  building  design,  a  third 
for  tranmlssion  tower  system  design,  and  so  forth.  The 
difficulty  with  this  approach  Is  the  duplication  of  effort 
that  Is  required  to  develop  unique  subsystems  for  each 
project  area.  The  development  of  the  STRUni  subsystem  as  a 
problem  oriented  capability  extended  over  five  years.  The 
duplication  of  that  effort  several  times  for  different 
project  areas  Is  worthy  of  little  consideration. 

Another  approach  to  Implementing  project  oriented 
capabilities  Is  specifically  that  of  the  supersystem.  Each 
project  area  would  have  not  a  unique  computer  capab’llty  but 
rather  a  unique  project  data  structure.  Thus  computer 
subsystem  developers  would  continue  their  current 
'.orientation  of  developing  problem  solving  capabilities.  Rut 
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FIGURE  1-3 


ICES  SUPERSYSTEMS 


each'  of  "t’h*ese~pro61  'em “'sol  vlrvjt  'capabVn tTes  woul  d  Wave  "  " 

additional/  satellite  features  that  would  allow  for  the 
Implementat  ion  of  data  transfer  between  -the  subsystem— and-  a 
specific  project  data  file.  The  existing  subsystem  would  be 
1  n  teg  rated  wrth  3  new  supersystem  by  the  1  mpl  emcntcHon  of 
the  satellite  data  transfer  capabilities  for  the  new  project 


data  file  (See 'figure  1-31.  'IT-  .17 

Iha  null  dins  ipikiLiiy, 

I n  the  United  States,  the  estimate  for  the  total 
va;ue  of  construction  during  the  year  1970  Is  set  at  $90 
billion  (8).  Table  1-1  gives  a  breakdown  by  project  type  of 
the  estimated  value  of  building  construction  during  the  same 
year  but  excluding  one  and  two  family  dwellings.  The  same 
estimate  predicts  a  greater  than  109  percent  Increase  In 
construction  value  during  the  Recede  1970-1980  to  a  value  of 
$193  billion.  The  estimate  of  the  gross  national  product  of 
the  United  States  for  the  years  1970  and  1980  given  by  the 
estimate  are  $900  billion  and  $1,930  billion  respectively. 
Furthermore,  In  the  United  States  the  Industry  Is  compose:! 


more  than  900,000  contractors  and  l,590,ono 
subcontractors  employing  over  3,000,000.  They  are 
supplied  by  a  myriad  of  other  Industries  employing 
large  numbers,  such  as  the  240,000  employees  of 
sawmills  and  planning  mills,  the  60,000  In  mlllwork 
and  related  products,  and  the  260,000  who  manufacture 
equipment.  To  handle  financial,  insurance,  and  real 
estate  dealings  requires  another  1,100,000  people  of 
whom  more  than  6u0,Q00  are  In  real  estate  alone.  The 
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TABLE  l-l  (9) 


Forecast  of  Construction  Contracts  -  1970 
“Muttons  of  Dollars 


Total  Construction  * . . . $52,225 

Heavy  Construction . S16,37$ 

Mon-Residential  9ui  ldlng. . 26,100 

Manufacturing . , . . . . $5,000 

Commerlcal . 8,700 

Educational . 6,000 

Medical . . . 2,700 

Government  Services . 1,000 

Recreational,  Religious,  Etc . .....2,700 

Residential  * . 9,253 

Apartments . 7,600 

Dormitories . 900 

Hotels  and  Motels . 750 


Excludes  one  and  two  families  dwellings 


— - tjtrf  1<Hngde$lgn  professions  lnc-lude30>GOO-,' eg!  s&ered 

architects  arid  75,000  engineers  plus  a  large  number , 
of  s pec  1  a  1  f  s  t  s .  Han  1  feat  1  y  the’  Industry  1  s'  iWge 
diffuse,  and  consists  of  a  Ioos-j  agglomeration  d'f 

_ mostly  s«naP  units.  The  number  of  design- 

construction  firms  with  an  annual  volume  greater'. thiib 
$500  mill  ton  can  be  counted  on  the  fingers  of  one 
hand.  Few  materials  and  equipment  producers  rank 
among  the  nation’s  500  largest  Industrial  firms.  (10) 

The  technical  areas  requl red  1 n  the  design  and  "  ' 


•construct ion  o-f  a  large  building  are  amazingly  diverse.  .Qne. 
can  consider  the  professional  and  economic  Interests  Of  the 


building  industry  as  falling  into  one  of  four  general 
categories*  management,  design,  construction,  and  finally 
operation  and  maintenance. 

The  realm  of  management  Includes,  first  of  all,  the 
client  or  owner.  The  client  Is  the  orlma  movens  of  the 
entire  Industry.  It  Is  he  who  dictates  the  kind  and  quality 
of  building  depending  on  his  needs  and  financial  backing. 
Owners  range  In  size  from  the  private,  single  home  builder 
through  developers  of  capital  Investment  motivated 
skyscrapers  in  large  metropolitan  centers  and  the  Federal 
government  with  all  of  Its  resources. 

Included  In  the  realm  of  economics,  however,  are  many 
other  professions  concerned  with  building.  These  Include 
planning  boards  for  urban  areas,  financiers  (including 
banks.  Insurance  companies,  pension  and  welfare  funds,  and 
government  mortgage  financing  agents),  real  estate 
developers,  zoning  commissions,  accountants,  and  che  like. 

The  second  realm  of  the  building  Industry  Is  that  of 


-•ieaijwu . Traditionally*  the  management  of  des ten  has  been  I  n 

the  hands  of  an  architect  who  acts  as  the  client's  agent  for 
both  design  and  construction.  9ut  due  to  the  widely 
divergent  and  highly  technical  nature  of  many  aspects  of 
building  design*  the  architect  (excluding  one  and  two 
-dweHIng  housing,  whicn  r*ore»e»tts  about  one^hal f  of  the 
construction-  dollar  value}  r eou l;r es._the  assistance  of 
professional  consultants  In  the.  ongl  non  ring  areas.  These 
generally  Include  the  structural  engineer*  the  foundation 
engineer*  the  mechanical  engineer*  the  elactlcal  engineer* 
and  specialists  in  the  areas  of  cost  estimating*  Interior 
design*  acoustics*  Illumination*  and  landscaping. 

The  third  realm  of  the  Industry  is  that  of 
construction.  The  construction  phase  of  the  building 
project  has  traditionally  been  managed  by  the  architect*  but 
the  prime  agent  here  is  the  general  contractor.  The  general 
contractor,  like  the  architect  In  the  design  realm*  uses 
specialized  sub-contractors  to  perform  the  highly  technical 
phases  of  the  construction.  These  sub-contractors  Include 
p’umbers*  heating  and  air  conditioning  specialists* 
electrical  contractors,  plasterers*  stone  masons* 
carpenters*  roofers*  structural  steel  erectors*  and 
foundation  contractors*  among  others. 

The  final  realm  Is  that  of  operation  and  maintenance. 


Included  here  are  the  ooeratlons  englnuers  required  to  keep 
large  mechanical  and  electrical  systems  for  buildings 


timet t onlng  proper  1  y,c lean Ingcrews/secu rl ty  personnel," 
and  the  construction  trades  required  for  repairs  and 
modi  fl  cat  Ions.  _ _  .. 

It  should  be  clear  that  this  diversity  of  economic 
Interests  and  Intellectual  disciplines  Involved  In  the 
building  Industry  lead  to  a  fragmentation  that  exists  on 
three  levels.  There  Isa  f ragmentat I on  oFpersonnel.  -The7 
nature  of  building  design  alone  Is  such  that  one  can  never 
expect  to  see  a  single  person  being  able  to  do  the  entire 
design.  There  Is  a  fragmentation  of  location.  For  the  most 
part  as  the  profession  Is  currently  carried  on,  the 
participants  In  the  design  and  construction  stares  each  have 
separate  offices,  sometimes  even  to  the  extent  of  being 
located  In  different  cities.  And  finally,  there  Is  a 
fragmentation  of  goals.  What  may  well  be  the  best 
structural  design  can  lead  to  a  definitely  sub-optimal 
mechanical  design,  and  vice  versa.  What  appears  best  In 
terms  of  Initial  cost  may  be  very  poor  when  considered  In 
terms  of  long  term  costs. 

The  major  consequences  of  this  fragmentation  are 
three.  By  far  the  most  Important  and  at  present  the  most 
widely  recognized  consequence  Is  the  communication  problem. 
Communication  Is  a  basic  aspect  of  the  design  and 
construction  of  buildings,  whether  all  of  the  design 
participants  work  In  a  single  office  or  not.  The  range  of 
design  disciplines  dictates  that  professional  Interaction 


- v? -  -  __ 

take  place.  The  budding  process  typically  starts  as  the 
desire  of  a  client  for  a  building  and  Is  developed  through 
Interviews  between  the  client  and  the  designer,  through  the 
various  design  stares,  to  a  fully  developed  set  of  contract 
drawings  and  specifications.  A  second  consequence  of 
fragmentation  ead  one  that  follows  also  from  the 
communication  problem  Is  that  of  sub~optimlzatlon  of  design 
A  less  than  perfect  communication  between  the  principal 
designers  makes  It  Impossible  to  estimate  how  their  design 
decisions  affect  each  other  and  consequently  how  such 
decisions  affect  overall  cost  for  the  client.  The  problem 
of  optimization  in  building  design  Is  as  much  a  matter  of 
communication  as  It  Is  of  mathematics.  And  finally,  a  last 
consequence  of  fragmentation  Is  duplication  of  effort.  As 
currently  practiced,  the  duplicate  review  of  drawings  and 
specifications  for  cost  estimating  by  architects  and  bH.lln 
by  contractors  Is  typical  of  this  duplication  of  effort. 

Consider  the  kinds  of  Incidents  that  occur  In  the 
current  state  of  building  design.  The  structural  and 
mechanical  engineers,  having  arrived  at  Initial,  compatible 
configurations  for  the  structural  frame  and  duct  system, 
return  each  to  his  own  office  where  detail  design  continues 
Later  the  architect  Informs  the  mechanical  engineer  that 
certain  changes  have  occurred  In  the  specification  of 
materials  for  3n  area,  thus  changing  the  heat  loads  and 
requiring  In  turn  a  larger  duct  servicing  the  area.  If  the 
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mechanical  engineer  falls  to  confer  with  the  structural 

engineer  'agal n,  as  happens -sometimes  when  t+re  desT-gn --f  s - 

rushed/  the  conflict  surfaces  only  when  the  contractor 
discovers  that  the  duct  Is  supposed  to  go  through  a 
structural  beam. 

One  of  the  reactions  to  this  fragmentation  has  been 
the  tendency  of  late  to  combine  In  one  firm  all  of  the 
principals  Involved  In  the  building  Industry  *  financier/ 
architect,  engineers,  and  contractor.  This  reunification  at 
least  within  the  same  firm  helps  alleviate  some  of  the 
problems  resulting  from  the  fragmentation.  Many  of  the 
goals  are  thereby  consolidated  and  the  problem  of 
communication  Is  generally  that  much  lessened. 

The  supersystem  concept  discussed  above  Is  another 
reaction  to  this  problem  of  fragmentation.  The  supersystem 
proposes  to  consolidate  all  of  the  Information  about  a 
project  in  a  central  file  of  data  where  It  Is  available  to 
all  design  participants  at  the  same  time.  Furthermore/  the 
availability  or  data  to  all  designers  potentially  allows  for 
studying  the  effects  of  design  decisions  main  In  one  design 
are*,  on  the  other  aspects  of  the  overall  design.  Thus 
engineers  can  design  In  terms  of  overall  project  goals 
rather  than  the  more  Immediate  goals  of  just  their  own 
discipline  area.  Finally,  the  development  of 
telecommunications  for  computers  whereby  engineers  using 
only  low  cost  terminals  in  their  offices  can  use  the  power 


-  J,r - 

of  large  computers  ,  and  data  fjlesl 1 terally  across  the 
country,  will  help  In  the  matter  of  locational  fragmentation 
where  It  continues  to  exist. 

Ike  Bull  dint  Process 

Having  viewed  building  construction  from  the 
viewpoint  of  an  Industry,  one  can  take  a  slightly  different 
approach  and  view  the  same  thing  from  the  viewpoint  of  a 
process.  Considered  as  a  process,  building  Is  composed  of 
various  phases. 

The  Royal  Institute  of  British  Architects  (11)  has 
Identified  twelve  stages  of  building  activity.  These  stages 
are  only  an  attempt  to  give  a  general  classification  to  the 
phase  of  activity  most  prevalent  at  the  Instant,  and  there 
is  no  claim  that  there  are  distinctly  recognizable  points  of 
transition  between  the  stages  or  that  all  designers  are  even 
In  the  same  stage  at  the  same  time.  The  phases  of  the 
building  process  Identified  by  the  Institute  are: 

I ncept 1  on  -  First  meetings  with  client  and 
establishment  of  design  team. 

Feas  Ibl  I  l.ty  -  Preparation  of  first  outline  from 
Interviews  with  client  and  assurance  that  outllnp  is 
feasible. 

Outl Ine  Proposal  -  Further  detailed  study  of  client's 
requirements,  costs  of  project,  and  approaches  to 
layout,  design,  and  construction. 

Scheme  Design  -  Final  development  of  preliminary 
design.  Including  full  design  by  architect  and 


preliminary  design  by  engineering  designers 


Detail  Design  -  Final  decisions  on  all  design 
matters . 

Pxa.'iuc.u  on  Lnf. or  Italian  -  Preparation  of  final  design 
drawings  and  specifications. 

Sill  A  af.  Quantities  -  Preparation  of  HI  is  of  - 

Quantities  for  construction  bids. 

Tender  Action  ^  Si d Ung  4>y  general  c«r.t r  ac to rs, 

Project  Planning  -  Construction  co-ordination  between 
general  contractor  and  hts  sub-contractors. 

Operations  op  Site  -  Actual  construction. 

Comol et 1  on  -  Completion  of  construction. 

Feed-back  -  Analysis  of  design,  construction,  and 
operation  of  building  during  Its  life. 

This  distinction  between  various  phases  of  the 
building  process  Is  important.  Clearly,  the  problems  and 
even  the  nature  of  communication  differ  during  the  various 
phases  of  building.  At  Inception,  Ideas  and  data  are  few, 
highly  unorganized,  constantly  changing,  and  even  geometry, 
a  fundamental  aspect  of  all  building  data  Is  In  a  very  fluid 
state.  By  the  start  of  preliminary  design,  most  of  the 
geometry  has  firmed  up,  and  the  real  problems  of 
communication  and  Interaction  among  designers  become  the 
most  Important  aspects  of  the  Information,  "y  final  design, 
the  sheer  volume  of  information  has  become  Its  most  critical 
aspect  and  It  Is  that  aspect  which  extends  through  the 
construction  phases.  It  Is  this  evolving  characteristic  of 
building  Information  (the  same  holds  for  the  Information  for 


4 


1« 

any  engineering  project)  that  makes  the  suh lect  of  oro feet 
data  management  such  a  difficult  one.  These  same  e^aneln* 
characteristics  will  dictate  explicit  requirements  for  any 
attempt  at  automated  data  management  as  will  become  evident. 

Hit*  tt»&  Mms  f »  In  ihfi  M ildlmt  EtasUss. 

The  very  fundamental  quest  I  on  of  why  the  computer 
should  be  used  at  all  In  the  building  process  Is  on';r  that 
should  be  faced.  In  this  age  of  mass  computerization  It 
might  seem  strange  that  such  a  question  be  phrased,  but  as 
the  complexity  and  cost  of  proposed  computer  systems  grow, 
more  and  more  are  coming  to  ask  Just  that  question. 

The  computer  with  its  allied  software  Is  just  another 
among  many  potential  tools  for  those  engaged  In  the  budding 
process.  Because  of  Its  tremendous  potential  for  extremely 
fast  calculations  and  large  capacity  data  manipulation, 
however,  the  computer  stands  as  a  particularly  significant 
tool  In  the  collection  of  the  building  designer  and 
contractor.  As  Miller  has  stated  It: 

Computers  are  the  key  to  a  systems  approach 
to  civil  engineering.  The  nature  of  contemporary 
projects  Is  so  large,  and  there  are  so  many  complex 
factors  and  components  -  all  these  different  kinds  of 
Information  must  be  tied  together,  and  the  only  way 
you're  going  to  do  it  Is  by  computer.  I'm  talking 
about  using  computers  at  Information  management 
devices  and  not  as  merely  computational  tools.  Only 
about  10$  of  our  problems  are  computational  by 
nature,  the  other  90?  are  problems  of  Information 
storage,  control,  and  manipulation.  (12) 

There  Is  little  question  of  the  computer's  capability 
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_ to  store  1 nformat 1  on .  Consider,  for  example,  the  ISM 

System/360,  Model  65,  computer.  Configured  with  one  million 
bytes  of  core  storage,  a  model  2301  drum  unit,  a  model  2314 
disk  stroage  unit,  and  a  model  2321  data  cell  drive,  such  a 
system  has  nearly  500  million  characters  of  on- 11 i'  storage r ~ 
one  million  characters  of  the  storage  can  be  accessed  I rr  — 

_ less  than  one  microsecond;  five  million  characters  of 

storage  can  be  accessed  In  less  than  ten  milliseconds;  over 
sixty  million  characters  of  storage  can  be  accessed  In  less 
than  one-tenth  of  a  second;  and  all  of  the  nearly  one  half 
billion  characters  of  storage  can  be  accessed  In  Just  over 
one-half  second  (13).  Understandably,  no  one  yet  really  has 
any  feeling  of  how  many  characters  of  data  would  be  required 
to  completely  describe  a  building  design.  But  there  Is 
little  doubt  that  the  computer  will  meet  the  task,  at  least 
as  regards  capacity.  The  situation  looks  even  more  hopeful 
with  speculation  that  the  next  generation  of  computer 
hardware  will  Improve  the  cost/performance  ratio  of  computer 
systems  by  a  factor  of  from  six  to  twelve  over  the  last 
generation  of  hardware  (14). 

Conte&l  ill  ihs.  Current  if  fact 

The  task  of  developing  automated  data  transfer  for 
the  building  industry  Is  truly  a  monumental  one.  The  size 
and  complexity  of  the  Industry  combined  with  the  range  of 
disciplines  that  are  involve!  In  financing,  designing,  and 


construct! nit  buildings  has  lead  to  much  hesitancy  to  even 
attempt  to  tackle  the  problem.  Clearly  no  one  effort  will 
be  completely  successful  In  such  an  undertaking  and  the 
current  v»orK  Is  just  the  beginning  of  what  wl  H  have  to  be  a 
long  process  of  research  and  evolution.  Tha  current  effort 
has  been  as  much  an  attempt  to  further  def  1 ne  the  problem  a s 
It  has  to  develop  a  working  solution.  One  of  the  things 
that  has  become  clear  1 s  that  the  sol ut t on  will  be  an 
evolutionary  process  rather  than  a  completely  developed 
working  capability  from  the  start.  In  the  current  effort, 
also,  -the  concentration  has  baen  placed  on  the  communication 
of  data  between  engineers  concerned  with  the  design  Of 
buildings,  rather  than  architects  or  the  construction  or 
operation  phases  of  the  building  process.  The  reasons  for 
the  emphasis  on  the  engineer  rather  than  the  architectural 
aspects  of  design  are  twofold.  First,  the  author  Is  an 
engineer  rather  than  an  architect.  8ut  more  significantly, 
architecture  Is  an  a theoretical  discipline.  An  architect 
considers  himself  to  be  an  artist  working  In  a  technical 
Industry.  The  consequence  of  this  is  that  architects 
structure  and  treat  data  differently  from  the  way  engineers 
do.  Hance,  while  the  designers  of  an  archl tectural  computer 
system  might  net  be  completely  happy  with  the  file  structure 
of  Information  that  will  be  considered  later,  their  system 
could  still  be  capable  of  feeding  Information  regarding 
geometry  and  materials  to  the  data  base.  These  two 


■Information,  areas.,  are  key.  comppoen.ts  f n.  -nany.  of  ihe  .. 
engineering  design  areas. 
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There  are  two  major  areas  to  be  Investigated  In  the 
Implementation  of  an  ICES  building  design  subsystems  data 

management  and  file  structure.  - _ 

The  concept  of  using  data  as  the  Integrating  bond  for 
a  building  system  leads  directly  to  the  fundamental  question 
of  data  management.  The  general  problem  of  data  management 
has  been  the  object  of  much  computer  research  and 
development  over  the  past  decade.  The  develooment  of  the 
generalized  data  management  systems  leads  one  to  consider 
their  value  for  the  problem  of  data  management  In  the 
building  context,  or  at  least  the  appropriateness  of  their 
approach  to  a  solution  for  this  problem. 

The  generalized  data  management  systems  have 
addressed  themselves  directly  to  the  problem  of  how  does  one 
manage  the  computer  environment  where  there  exists  a  large 
corpus  of  data  about  some  loosely  structural  logical  entity 
(generally  a  corporate  or  military  operation)  which  must  be 
developed  and  used  by  a  group  of  Independent  computer 
systems,  none  of  which  Is  responsible  for  all  of  the  data 
and  all  of  which  must  share  the  use  of  the  data.  This  Is 
exactly  the  problem  faced  In  the  bulldln^  realm. 

While  the  use  of  the  generalize  I  lata  management 


systems  in.  the  context  of  building  systems  he*  *>•»*> 
drawbacks,  the  ICE?  systems  as  currently  Implemented  does 
have  some  data  management  capabilities.  The  tCE?  TABtE-ll 
system  has  file  structure  capabilities  and  storage  and 
retrle*'‘j1  funct  Ions. 

~  '  The  TA6LE-I I  f tf e  structuring  capabilities  are 

:.„P-arv  Leu  Laclx  appropriate  fo  r  the  pr  oblemofstor  ingriynnmic 
Information  In  a  file  on  secondary  storage.  This  system, 
like  the  generalized  data  management  systems,  stores 
Information  In  such  a  manner  that  Its  location  and 
characteristics  are  remembered  by  the  system.  Furthermore, 
data  are  Identified  by  name  In  such  a  way  that  one  need 
I  murely  provide  the  system  with  the  name  and  the  system  Is 
able  to  retrieve  not  only  the  value  hut  also  Information  as 
.to  what  the  characteristics  of  the  data  are  (dimensional 
— -uni ts  and  computer  characteristics ),  Conceottial ly,  the 
Information  Is  structured  as  a  four  level  trees  table,  rent, 
column,  and  list  position. 

The  feature  of  having  available  a  file  system  which 
uniquely  Identifies  and  manages  datn  within  the  system  Is  of 
primary  Imoortance  In  the  are3  of  building  systems  (as  well 
as  many  other  systems).  The  problems  of  managing  a  growing 
corpus  of  Informat 'on  used  by  completely  Independent 
computer  systmes  demands  that  one  consider  only  a  data 
management  syrtem  capable  of  treating  the  Information  as  a 
growing,  dynamic  entity.  The  classical  approach  of  file 


structu re  based  on  ioc^tioi^i  conventions  -4 s  c  inar-iy  out  -of— 
the  question  In  such  a  situation.  Such  an  approach  always 
demands  a  fixed  file  targe  enough  to  hold  the  largest  amount 
of  data  one  can  desire  for.  Furthenorey  ?t  Is  generally 
Impossible  to  Identify  the  condition  where  data  values  are 
missing  ■  where  they  have  not  been  stored  yet.  the 
integration  of  'Various  computer  systems  for  dTfferaajt- — — 
discipline  areas  requires  that  Information  regarding 
dimensional  aspects  of  the  data  be  maintained  as  well  as  the 
convenience  of  automatic  conversion  of  dimensions  on 
request. 

The  TABLE-1 1  system  has  the  additional  feature  that 
there  are  currently  available  a  collection  of  storage  and 
retrieval  functions  for  passing  Information  in  either 
direction  between  an  engineering  program  and  a  secondary 
storage  file.  The  TABLE-1 t  subsystem  is  rather  unique  amnns 
the  ICES  subsystems:  It  exists  on  both  the  enp inerr-user 
level  as  a  problem  oriented  language  subsystem  and  on  the 
programmer-user  level  as  the  collection  of  storage  and 
retrieval  functions. 

The  file  structure  for  a  computer  bas/.-d  1  nfor  ,iat  Ion 
system  must  closely  reflect  the  structure  of  the  data  as  1 1, 
Is  used  bv  the  designers.  The  file  structure  for  a  building 
Information  system  must  be  based  on  the  character I s* ‘ cs  of 
the  use  of  data  by  the  engineers  an J  the  architect.  Each  o* 
these  people  has  a  responsibility  which  Is  uniquely  his  own. 
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-The  architect  -is  responsible  jfor-ihe -geometry -.AnjLJ ayoiii _ 
the  spaces  as  well  as  the  sped f Icat Ion  of  the  materials  of 
the  walls  and  other  surfaces;  the  structural  engineer  Is 
responsible  for  the  structural  frame  required  to  support  the 
loads  In  the  building;  the  electrical  engineer  for  the 
distribution  of  electrical  power  throughout  the  building  as 
— required:;  the- mechanical  engineer  -for-th^  system  of  a!  r 


ducts  for  the  delivery  of  hot  and  cold  air  to  the  spaces  and 
the  removal  of  waste  air  from  the  system.  Each  of  these 
designers  has  a  realm  of  data  which  he  develops  In 
conjuctlon  with  the  objectives  and  retirements  of  th« 
others  connected  with  the  project. 

Thus,  while  the  architect  generally  has  the  principal 
concern  with  windows  as  an  element  of  form,  his  decisions  on 
windows  greatly  Influence  the  heat  loads  that  are  the 
responslbll ! £y  of  the  mechanical  engineer  end  the  amount  of 
1 ightlng  which  Is  the  responsibility  of  the  electrical 
engl neer . 

The  file  structure  for  a  computer  based  Information 
system  of  building  design  data  must  be  organized  around  the 
use  of  data  by  the  various  agents  primarily  concerned  with 
that  data,  and  the  data  within  a  file  should  he  structured 
In  such  a  way  as  to  reflect  the  relational  ani  algorithmic 
structure  of  the  data.  The  data  regard!  nr  windows  shoul  d  !>i 
the  responsibility  of  the  architect.  Me  Is  the  designer 
primarily  responsible  for  choosing  the  quality  and  location 
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DESCRIPTION 
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-^f-i<*Tndows  .--Also -the  location  of  Info  nation  about  the 
windows  among  all  of  the  lata  I  terns  which  fall  Into  the 
realm  of  the  architect  should  reflect  the  fact  that  windows 
are  located  in  wall*/  walls  which  delimit  two  spaces. 

With  a  file  so  structured,  the  mechanical  engineer  In 
doing  heat  load  analysis  can  Interrogate  the  data  base  of 
^the  architect  regarding  the  room  under  consideration,  asking 
for  the  U-factors  for  each  of  the  walls  and  be  told  that  a 
particular  wall  has  a  window  of  some  specific  size  and  that 
the  design  temperature  minimum  on  the  other  side  of  that 
window  during  the  window  is  -20  degrees  Fahrenheit. 
Furthermore,  the  electrical  engineer  can  query  the  sa.r*e  file 
of  the  architect  and  learn  that  the  room  has  a  window  with  a 
southern  exposure  and  hence  has  a  calculable  flux  of 
sunsh I ne. 

The  macro  level  file  structure  proposed  for  a 
building  environment  Is  outlined  in  Figure  l-fc.  This 
represents  a  first  effort  at  a  file  structure  of  this  sort. 
As  work  proceeds,  further  refinements  on  the  various 
sub-files  and  their  relationships  will  become  apparent. 
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